home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Jul 89 / W0101-Re Typecasting-Jul89 < prev    next >
Encoding:
Text File  |  1989-08-22  |  3.0 KB  |  80 lines  |  [TEXT/GEOL]
  1. Item    9114656                         20-July-89        16:36
  2.  
  3. From:   ALGER                           Alger, Jeff
  4.  
  5. To:     ROSENSTEIN1                     Rosenstein, Larry
  6.         ARBOGAST                        Peat Marwick, Chris Arbogast
  7.  
  8. cc:     MACAPP.TECH$                    MACAPP Tech
  9.  
  10. Sub:    Re Typecasting
  11.  
  12. Larry and Chris,
  13.  
  14. I think you are both right to an extent regarding type casts in Object Pascal.
  15. The casting code generated by the compiler is consistent with Pascal's roots as
  16. a (relatively) strongly typed language.  Larry, your point is well made that
  17. this strong typing is one of the central reasons many people prefer Pascal over
  18. a weakly typed language like C.  Chris, you are correct that not all
  19. programmers agree that strong typing yields a positive cost-benefit.  On
  20. balance, since the domain of discourse here is Pascal I have to agree with
  21. Larry: if you dislike strong typing, use a less strongly typed language than
  22. Pascal.
  23.  
  24. Second observation: a cast of NIL should be legal in all cases.  The usual
  25. treatment of NIL from a formal semantics point of view is that NIL means
  26. "unknown", not "nothing."  This is the reason that NIL is a valid value for
  27. every object class variable or expression.  By consequence, NIL should typecast
  28. to every class.
  29.  
  30. Much of the discussion has revolved around examples where the value of a
  31. completely unitialized variable is assigned to some other variable:
  32.  
  33. PROCEDURE TestProc;
  34. VAR
  35.     aFoo: TFoo;
  36.     aFoo2: TFoo2;
  37. BEGIN
  38.     aFoo2 := TFoo2(aFoo);
  39. END;
  40.  
  41. I find this to be a poor choice of example and have little sympathy with anyone
  42. who gets into trouble this way.  (In fact, many optimizing compilers would
  43. issue an error or warning at this reference to an obviously random value.)
  44. More likely, a variable initialized to NIL would be cast and assigned to
  45. another; this should definitely be legal!  To wit:
  46.  
  47. PROCEDURE TestProc;
  48. VAR
  49.     aFoo:   TFoo;
  50.     aFoo2:  TFoo2;
  51. BEGIN
  52.     aFoo := NIL;
  53.     aFoo2 := TFoo2(aFoo);
  54. END;
  55.  
  56. This should be legal, since NIL is a legal value for both classes.  The same
  57. reasoning applies to member(NIL, someClass), although I maintain that this
  58. should be TRUE, not false, for all classes by the same reasoning: NIL is a
  59. legal value for every class!
  60.  
  61. Third observation: the following example does have an unambiguous meaning and
  62. should be legal:
  63.  
  64. TFoo(aFoo2) := aFoo;
  65.  
  66. The left hand side of the assignment is fine as long as the cast is proper: it
  67. need only evaluate to the address of an object (in the loose sense of "object")
  68. of a compatible data type into which the value of the right hand side can be
  69. stuffed.  Pascal is stickier on this point than C in that C allows any
  70. arbitrary expression on the lhs, but there is no need to carry this to the
  71. extreme of not allowing the above cast.
  72.  
  73. There are other areas of OP which suffer from hokey semantics as well, but
  74. typecasting of object handles is one of the most visible and should be cleaned
  75. up as soon as possible.
  76.  
  77. Jeff Alger
  78. Peat, Marwick, Main & Co.
  79.  
  80.